1. Field of the Invention
The present invention relates to the field of data communications networks. More particularly, this invention relates to a method and apparatus for unifying the operation of authentication, authorization and accounting services and proxy services in a data communications network.
2. The Background
ISPs (Internet Service Providers) and Telcos (telephone companies) typically offer wholesale internet access and retail internet access to their subscribers. Wholesale access is typically offered to subsidiary and specialized service providers, CLECs (Competitive Local Exchange Carriers), corporations, and Community of Interest (COI) providers. Naturally, the processing afforded customers of the wholesale variety differs from the processing afforded customers of the retail variety. Subscriber information for individual wholesale users is usually stored by those who lease data communications network access from the ISP or Telco. Hence, corporations, CLECs and COI providers do not normally share their user information with the wholesale providers. The ISP or Telco, however, typically also has its own retail subscribers whose user information is stored in its databases. Hence, the ISP or Telco must identify an incoming user as a wholesale user or a retail user and initiate different actions for an incoming user based upon this status.
See, for example, FIG. 1 where a pure retail environment has a number of network access servers (NAS1, NAS2 and NAS3) which provide data communications portals to the ISP's point of presence (PoP) on the data communications network. Each NAS is in communication with a conventional AAA (authentication, authorization and accounting) service maintained by the ISP. Incoming users connect to the NASes by dialing in over the telephone network or in another conventional manner.
Traditional wholesale ISPs and Roaming Service Providers offer network access through a technique called “Authentication proxying.” Proxying involves the transfer of the Authentication responsibility to the “owner” of the subscriber. Thus, if a corporation was to outsource its corporate intranet to an ISP, what it gives up is the maintenance of its dial-up servers (i.e., the NASes). It does not, however, normally want to give up the control or information of its employees. Hence, when a corporate user dials in to such an ISP's network access servers, the user essentially perceives that the user is dialing into a corporate facility when the user is actually dialing into the ISP's domain and then somehow gaining admittance to the corporation's intranet.
What really happens in that scenario is that the ISP determines that the user belongs to Corporation A(CorpA) by parsing either the fully qualified domain name (FQDN) supplied by the user, a DNIS ID, or some other mechanism. Having determined that the user trying to gain access belongs to CorpA, the ISP cannot really authenticate the user. As noted earlier, the user's record is still with the corporation. Hence, the ISP will “proxy” out the authentication transaction to the corporation. An AAA service within the corporation then identifies the user, verifies the password, and provisions the user. Then the AAA service notifies the ISP's proxy server that the user is acceptable and passes along provisioning details associated with the user (such as an IP address to use or a pool identification of an IP address pool from which an IP address needs to be allocated). The ISP then grants the user access to the network based upon the reply it gets back from the corporation. This technique is called “proxying.” This is shown in FIG. 2.
To be able to do this, the ISP maintains minimal information on its proxy server 14 at its PoP. Information such as supported domain names, the IP address to which the transaction is to be sent, the port number to which the transaction is to be addressed, etc. are stored (see FIG. 3).
For example, turning now to FIG. 2, user Joe@corpa.com dials in 40 to NAS1. A PPP (point to point protocol) session is raised between Joe and NAS,. An IPCP (internet protocol control protocol) session 42 is raised between NAS1, and proxy service 44. In response NAS1 sends a RADIUS (Remote Authentication Dial-In User Service protocol) access-request to proxy service 44. Proxy service 44 then consults its local configuration database 16. Proxy service 44 then makes a determination about where to send the access-request packet. Here it decides to send it to the AAA service 48 maintained in the CorpA domain 50. The CorpA AAA 48 then consults its local database 52 and authenticates joe@corpa.com. CorpA AAA 48 then returns an access-accept packet to proxy service 44 which, in turn, sends an access-accept packet to NAS1 completing the log-in of joe@corpa.com.
When the subscriber is granted access, or leaves the network, the accounting transactions will now have to be shared with the wholesale customers of the ISP/Telco. That is, the ISP/Telco will keep a record with which to bill or otherwise account to CorPA for services rendered and the record will also need to be sent to CorpA's AAA. Typically, the wholesale provider (e.g., the ISP) will use a roaming service product such as the Global Roaming Server™ (GRS), a product of Cisco Systems, Inc. of San Jose, Calif., to achieve this objective. In the retail case, the ISP/Telco will use a product like Cisco Secure™, a product of Cisco Systems, Inc., to act as an authentication, authorization and accounting (AAA) service to authenticate and authorize the user. This approach, however, poses some problems for the ISP/Telco.
The ISP/Telco needs to maintain two different sets of NASes as diagrammed in FIG. 4 or it has to pipe all transactions through a GRS (proxy service) as diagrammed in FIG. 5 which then has to make a decision as to whether the access-request transaction will be locally processed by the ISP/Telco (retail user) or remotely processed by the wholesale customer (wholesale user). The two products are independent products which maintain their own databases. They do not at present support a distributed architecture and hence will not scale by the number of PoPs users, etc. This poses the problem that multiple instantiations of the GRS will need to be configured and will not be able to properly load balance among the various NASes available at the PoP. Furthermore, should a GRS go down, the PoP may lose the services of the NASes in communication with the GRS that failed.
Accordingly, it would be desirable to provide a capability for allowing ISPs and Telcos to seamlessly offer wholesale and retail data communications network access, unify the disparate systems that specialize in these access control segments and scale both systems to simultaneously reside on a plurality of PoPs while behaving in a distributed manner within the data communications network.